This invention relates to a service registry and repository system and method. In particular this invention relates to a service registry and repository database system and method for a saving and restoring a faceted selection.
Service oriented architecture (SOA) is a business-driven information technology (IT) architectural approach that supports integrating the business as linked, repeatable business tasks, or services. The basic building block is a service document that defines a service so that it may be managed with other services. A service document contains information about a service including the location of the service and details about the service and how to access the service. Service documents may be used by analysts, architects, and developers during a Development Phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service documents are variously described as metadata, objects, descriptions, entities and artefacts.
A service repository stores the service document and allows access to the service document and thereby the corresponding service. A service registry is an index of a subset of information about a service (for example the location and name of service document) enabling the corresponding service document to be located and accessed in a repository (or even the corresponding service located at the service provider). An integrated service registry and repository allows a service operation to use both the indexed service information in the registry and the detailed service information in the repository. An example of an integrated service registry and repository is IBM® WebSphere® Service Registry and Repository (WSRR).
Such an integrated service registry and repository has advantages of greater business agility and resilience through reuse than separate systems. Further advantages of looser coupling, greater flexibility, better interoperability, and better governance arise from the integration. These advantages are addressed by separating service descriptions from their implementations, and using the service descriptions across the life cycle of the service. Standards-based service metadata artefacts, such as Web Service Definition Language (WSDL), extensible mark-up language (XML) schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it may be invoked, or what it expects other services to do. Semantic annotations and other metadata may be associated with these artefacts to offer insight to potential users of the service on how and when it may be used, and what purposes it serves.
A number of database applications provide users with the ability to refine a collection of data items by applying cumulative filters to the collection. As each filter is applied, the number of items in the collection is gradually reduced as the elements in the collection that do not match the filter are removed. When presented with a large collection of items this technique allows users to “drill down” to find the item or items that they are interested in. Some applications then allow the user to store the resulting selection away for later use. When the user runs the selection again, the filters that were applied are again presented so the user may further refine the selection. An example of such an application is the web-based user interface for IBM® WebSphere® Service Registry and Repository (WSRR).
Traditionally, drill down functionality has been implemented in one of two ways. First, the selection criteria may be expressed as a single selection string in some language such as extensible markup language (XML) Path Language (XPath). The problem with this solution is that applied filters may be stateful and the states may not be represented in the final selection string. An example of this in WSRR is the type of object the selection was previously filtered by before a Business Model filter was applied; this may be either GenericObject or BaseObject, but the selection string with a Business Model filter does not reflect this. Second, an algorithm to extract the selection criteria is implemented as a single, monolithic, process or function. The problem with this solution is that the filters may be based on various attributes of the items in the result set. Adding a new type of filter to the application may require changes to the application code and are, therefore, not a flexible solution.